[LTI Provider] Basic LTI authentication - #8501
Conversation
This is an initial authentication implementation that allows LTI users to log in transparently to edX. The behavior is driven by pilot users at Harvard; this was the most requested feature. The patch creates a new database model that maps users' LTI identifiers to newly-created edX accounts. If an LTI launch comes in with a user_id field that is not in the database, a new edX account is created with a random user name and password. This account is then stored in the database, so that it is permanently associated with the LTI user ID. This patch takes a simplistic approach to session management. If a user is logged in with a different account when they perform an LTI launch, they will be logged out and then re-logged in using their LTI account. In order to keep the patch simple, I have split out some refactoring that needs to be done into a separate branch that I'll post once this has been merged. Since we no longer redirect to the login page, we don't need to maintain two separate LTI endpoints (one for the LTI launch and one for authenticated users), or deal with the session management that requires. There are also multiple fetches of the LtiConsumer object (one in the view, one in the signature validation) that the later patch will consolidate into one. This branch fixes the previous conflicts with the test refactoring carried out in PR 8240.
|
Thanks for the pull request, @mcgachey! I've created OSPR-646 to keep track of it in JIRA. JIRA is a place for product owners to prioritize feature reviews by the engineering development teams. Feel free to add as much of the following information to the ticket:
All technical communication about the code itself will still be done via the Github pull request interface. As a reminder, our process documentation is here. |
|
@mcgachey to confirm this is now rebased atop master and resolves hopefully the failures that were seen last night? |
|
@sarina - That's right. This is a new branch spun off this morning with the same changes applied, and with fixes to the refactored tests. |
|
LGTM. @ormsbee can you take a glance and then be responsible for merging? Thanks |
|
Yup, 👍 again. I'll merge. |
[LTI Provider] Basic LTI authentication
This change cleans up the work in progress request at #8176
This is an initial authentication implementation that allows LTI users to
log in transparently to edX. The behavior is driven by pilot users at
Harvard; this was the most requested feature.
The patch creates a new database model that maps users' LTI identifiers
to newly-created edX accounts. If an LTI launch comes in with a user_id
field that is not in the database, a new edX account is created with a
random user name and password. This account is then stored in the
database, so that it is permanently associated with the LTI user ID.
This patch takes a simplistic approach to session management. If a user
is logged in with a different account when they perform an LTI launch,
they will be logged out and then re-logged in using their LTI account.
In order to keep the patch simple, I have split out some refactoring
that needs to be done into a separate branch that I'll post once this
has been merged. Since we no longer redirect to the login page, we don't
need to maintain two separate LTI endpoints (one for the LTI launch and
one for authenticated users), or deal with the session management that
requires. There are also multiple fetches of the LtiConsumer object
(one in the view, one in the signature validation) that the later
patch will consolidate into one.
This branch fixes the previous conflicts with the test refactoring
carried out in PR #8240.